As the web browsing experience continues to evolve from a flat presentation of information with minimal interactivity to a richer application or applet experience with lots of interactivity at the client side, or more generally, a hybrid of information display and richer interactivity with objects on display, there are a variety of challenges based on evolving the old document object model (DOM) originally designed primarily for flat presentation of information based on native code on a client to an experience that fluidly handles script code, such as JavaScript objects. For instance, speeding the user experience up remains a challenge.
For instance, with fly out menus of the past, the web experience flickered with delays based on communications with the server. Script enables small programs to modify the DOM on the fly without returning to the server for additional help, e.g., Asynchronous JavaScript and extensible markup language (Ajax). As developers and consumers alike want to do more dynamically on the fly without returning to the server, making script code execute fast on the client side has become a challenge.
Since the user experience centers on scripting the DOM, changing the DOM slowly makes for poor interactive response. Communication between the scripting engines and the native classes of the DOM were poor in the past due to the use of OLE automation including a set of interfaces, iDispatch, iActiveScript, etc., which make any object scriptable. In addition, a variety of Component Object Model (COM) objects may be indiscriminately created today, but which may be unnecessary, slowing down performance.
Client-side scripting, which can make web pages more responsive to user input once on the client browser by avoiding one or more round trip communications with a server, generally refers to the class of computer programs on the web that are executed client-side, by the user's web browser, instead of server-side (on the web server). As an example, client side scripting is a part of dynamic hypertext markup language (dynamic HTML or DHTML), enabling web pages to be scripted, e.g., in scripting languages such as JavaScript (client-side JavaScript) and VBScript, to have different and changing content depending on user input, environmental conditions, such as the time of day, or other variables.
Client-side scripts that are embedded within a markup document are sometimes referred to as “embedded scripts”, and scripts that are contained in separate files, which are referenced by the document(s) that use the file, are sometimes referred to as “external scripts”. In response to a request, such script files are sent to the user's computer by network computing devices, such as web server(s), on which the files reside. In this regard, in order to execute the script and display the markup document including any visible output from the script, the web browser works with a script engine to parse and compile the script code. Client-side scripts may also contain instructions for the browser to follow in response to certain user actions, e.g., clicking a button. Often, these instructions can be followed without further communication with the server.
As a trend, web browsers and web pages are tending to employ more and more client-side scripting, accounting for an improved user interface in which the user does not experience unfriendly “refreshing” of a web page, but instead sees, for example, an icon representing an animated Graphic Interchange Format (GIF) file representing that the request for the GIF file occurred and that portion of the page will be updated shortly. Adding to JavaScript capabilities, Ajax allows client machines and developers of scripted documents to communicate with network computing devices, such as web server(s), in the background without requiring a new version of the page to be requested and rendered.
While generally leading to improvements in user experience, this leads to other latencies where setup time takes too long on the client side. For instance, where a heavy amount of scripting is employed in a web site as tends to be the case for the top 100 web properties, or where network data transfer rates are slow, or where processing on the client is otherwise limited, the script engine can take too long to deliver up all of the executable code for presentation of the content of the markup document leading to a poor user experience.
In this regard, conventional web browsing has evolved in a way that leads to inefficient creation of executable code by the script engine because there is no discrimination by the script engine regarding script code creation, leading to unwanted latencies while the script engine completes its work for presentation of the scripted markup document. Such unwanted latencies can create a significant drag on user experience, particularly where a user may not need or want to wait for all web site functionality to load before beginning an interaction.
The above-described deficiencies of today's script engines and code generation are merely intended to provide an overview of some of the problems of conventional systems, and are not intended to be exhaustive. Other problems with the state of the art and corresponding benefits of some of the various non-limiting embodiments may become further apparent upon review of the following detailed description.